1. Field of the Invention
The present invention relates to a digital contents distribution system, a digital contents distribution method, a roaming server, an information processor, and an information processing method, and more particularly, to a digital contents roaming service using an intellectual property right protection system.
2. Related Background Art
FIG. 1 is a diagram showing a conventional digital video data transmitting and receiving system.
Referring to FIG. 1, a digital video data distribution server 10 is provided with a digital video data storage device 12, such as a hard disk, in which a digital video data is recorded in advance. The digital video data distribution server 10 downloads digital video data from the storage device 12 to a receiving client 20 through a network, e.g., the Internet according to a request from the receiving client 20. The distribution server 10 has a conversion section 11 for encoding digital video data. The distribution server 10 encodes digital video data in the conversion section 11 to reduce the amount of data, and delivers the encoded data to the receiving client 20 through the procedure in accordance with the Transmission Control Protocol/Internet Protocol (TCP/IP) or the like.
The receiving client 20 has a conversion section 21 for decoding digital video data. The receiving client 20 reproduces a digital video signal from received data in the conversion section 21, and records the reproduced signal in a digital video data storage device 22 or displays a reproduced video on a display device (not shown).
One moving picture scene is formed so as to be constituted by a plurality of objects. Each object is compressed by being encoded in the conversion section 11 of the distribution server 10. The encoded objects are decoded and reconstructed at the receiving client 20 to reproduce the moving picture scene. This reproduction system is, for example, an MPEG-4 (Moving Pictures Experts Group Phase-4) player.
FIG. 2 shows the configuration of a conventional MPEG-4 player.
FIG. 2 is formed on the basis of “ISO/IEC SC29 14496-1 FIG. 1-1”, details of which are described in “ISO/IEC SC29 14496-1”. This system will be only outlined with reference to FIG. 2.
An MPEG-4 bit stream transmitted over a network or the like or an MPEG-4 bit stream read out from a recording medium (storage medium) such as a digital versatile disk read-only memory (DVD-ROM) is received at a “TransMux Layer” through a procedure corresponding to transmission/read (establishment of session) and is separated, decoded and reproduced as streams of scene description data, object data, and object description data in “FlexMux” sections. Scene reproduction or graphical processing of the data is performed on the basis of scene description data.
Specifications relating to a case where authentication is required with respect to each of objects for the purpose of copyright protection are omitted in FIG. 2.
FIG. 3 is a schematic diagram formed by simplifying FIG. 2. If there is a need for authentication with respect to each of objects for the purpose of copyright protection or the like, an “IP Data Set” (intellectual property right (e.g., copyright) information group) may be included in a bit stream containing scene description data and a plurality of object data groups.
However, even if an “IP Data Set” (intellectual property right information group) is included in a transmitted bit stream, and even if the “IP Data Set” is reproduced in “object Descriptors” in the system shown in FIG. 2 or 3, no processing is performed with respect to the “IP Data Set” at the time of video reproduction processing, so that “IP Protection” (intellectual property right protection) processing is not executed.
It is, of course, possible for a certain application on the reproducing side to receive the decoded “IP Data Set” and to execute “IP Protection” processing. However, this processing is specific to this application, and the same processing is not always performed in other players or other models.
Also, in the system shown in FIG. 2 or 3, a video is reproduced after the completion of authentication with respect to each of the objects. In a case where new objects appear successively during reproduction of a moving picture scene, there is a need to temporarily stop the reproduction to perform authentication each time a new object appears.
FIG. 4 shows the configuration of an MPEG-4 player formed by adding an intellectual property right (e.g., copyright) protection system (IPMP System) and an object data processing flow control section (IPMP Stream Flow Control) to the system shown in FIGS. 2 and 3.
An MPEG-4 bit stream containing video object coded data requiring intellectual property right protection is divided into individual object data groups at Demux Layer 21 and the divided object data groups are converted and synchronized with respect to player internal time according to Sync Layer 22 coding and time stamp information added at the time of forming of the bit stream.
On the other hand, IPMP System 26 performs authentication processing on the basis of copyright protection information separated at Demux Layer 21 with respect to each separated object data group requiring intellectual property right protection, and delivers a permission signal to IPMP Stream Flow Control 23 to enable object data processing flow control. The data is decoded at Compression Layer 24 by a decoder corresponding to each object, scene composition is performed at Composition Layer 25 according to the decoded scene description, and the result of scene composition is displayed.
There are several possible methods for the object data processing flow control in particular. Problems to be solved will be described by referring to Test Conditions #1 and #2 by way of example.
Table 1 shows four test plans as an example of means for explaining the relationship between an IPMP System (IPMPS) and Stream Flow Control.
TABLE 1Test 1Test 2Test 3Test 4In Table 1, an Unprotected Text Object Stream is expressed as “t”, a Protected Audio Stream is expressed as “S1(Ca)”, and a Protected Video Stream is expressed as “S2(Cv)”.Also, an IPMP System for S1(Ca) is expressed as “IPMPS1”, and the result of XOR between original coded data and the code “x” in ASCII is set as “S1(Ca)”. Accordingly, a decipherment “key” is the code “x” in ASCII and decipherment is performed through an XOR operation with the “key”.Also, an IPMP System for S2(Cv) is expressed as “IPMPS2”, and the result of XOR between original coded data and the code “a” in ASCII is set as “S1(Cv)”.
In Table 1, an Unprotected Text Object Stream is expressed as “t”, a Protected Audio Stream is expresses as “S1(Ca)”, and a Protected Video Stream is expressed as “S2(Cv)”.
Also, an IPMP System for S1(Ca) is expressed as “IPMPS1”, and the result of XOR between original coded data and the code “x” in ASCII is set as “S1(Ca)”. Accordingly, a decipherment “key” is the code “x” in ASCII and decipherment is performed through an XOR operation with the “key”.
Also, an IPMP System for S2(Cv) is expresses as “IPMPS2”, and the result of XOR between original coded data and the code “a” in ASCII is set as “S2(Cv)”. Accordingly, a decipherment “key” is the code “a” in ASCII and decipherment is performed through an XOR operation with the “key”.
“Graceful Error” is an error caused in downstream of the decoder due to failure in normal decipherment of the protected object stream with the “key” and is not namely a “fatal error”. For example, possible “Graceful Errors” in the case of the protected video object stream are as expressed by “not displayed”, “a disturbed picture is displayed”, etc.
Table 2 shows conditions and parameters in IPMP Verification Tests.
IPMP Verification Test Condition and ParametersConditionTest 1Test 2Test 3Test 4ContentsCtUnprotected Text←←←S1 (Ca)Protected Audio←←←S2 (Cv)Protected Video←←←IPMPConditionIPMP-ES and IPMP-DyesyesyesyesIP IdentificationyesyesyesyesData SetIPMP-S1noneXOR ‘x’ for S1 (Ca)noneXOR ‘x’ for S1 (Ca)IPMP-S2nonenoneXOR ‘a’ for S2 (Cv)XOR ‘a’ for S2 (Cv)TestCondition#1noneEmbedded ‘key’←←& constant delay#2noneUser interaction←←& non-fixed delaySynchronizationyesyesyesyesExpected resultCt; passCt; passCt; passCt; passS1 (Ca); errorS1 (Ca); passS1 (Ca); errorS1 (Ca); passS2 (Cv); errorS2 (Cv); errorS2 (Cv); passS2 (Cv); pass
Referring to Table 2, when Test 2 is executed under Test Condition #1, the proper “key” for each of the object streams exists in the IPMP System (IPMPS1, IPMPS2) to immediately “decipher” each incoming object stream, and the deciphered object stream is output to each decoder.
When Test 2 is executed under Test Condition #2, no proper “key” for each of object streams exists in the IPMP System (IPMPS1, IPMPS2), the proper “key” is input by a user interactive method, such as by external key-inputting or by inserting a smart card to “decipher” each incoming object stream, and the deciphered object stream is output to the decoder.
FIG. 5 is a diagram showing internal functional blocks and data flows in an example of an MPEG-4 System Player. FIG. 5 is drawn as a simplified diagram for explanation of a sync mechanism, in which an illustration of an IPMP System and object data processing flow control is omitted.
First, an entry function, Execute( ) of the MPEG-4 System Player initiated by an application invokes each of functional modules, secures data area buffers, and performs memory allocation for each of functions in functional entities, etc., thus making preparations for data processing.
An input MPEG-4 bit stream is received by FlexDemux 31 which is a Service module function in the DMIF layer. Packet data or a data file from a network is received as a sequence of data groups to be delivered to an ALManager 32 functional block.
In ALManager 32, data groups are separated with respect to kinds of object, e.g., video data, audio data, and scene description data to form streams in data channels. Scene description data and data in information relating to objects are delivered to BIFSDecoder 33 while video data and audio data are delivered to Decoder 34.
In Presenter 35 and a Media Stream data processing section (not shown), adjustment of the time relationship among decoded Media Object data groups (Video, Audio data), synchronization between the data groups and scene composition are performed on the basis of scene description information decoded by BIFSDecoder 33 and Decoder 34 and time stamp information added at the time of forming of the bit stream.
FIG. 6 outlines the above-described sequence of data processing.
Referring to FIG. 6, FlexDemux 31 receives an MPEG-4 bit stream and separates it into elementary streams (ES) with respect to each kind of object data. ALManager 32 then divides the ES of each kind of object data on a decoding unit basis, and BIFSDecoder 33 and Decoder 34 perform decoding processing of each kind of object. A decoded data group Media Stream of each kind of object data is thereby formed. Presenter 35 performs time adjustment of each object data group by using a “MediaStreamImp::Fetch()” function for processing of Media Stream Data, combines each of the object data groups into one scene, and displays the scene.
FIG. 7 is a diagram showing an example of data processing for time adjustment. Time adjustment processing in Presenter 35 will be described in detail with reference to FIG. 7.
First, in step S71, a tolerance value is added to the current time of the System Player (→dwCurrentTime). In step S72, data to be processed (AU: Access Unit) is obtained. In step S73, time stamp information (TimeStamp) on the data to be processed (AU) is converted into a System Player time (→dwTime). In step S74, the current time (dwCurrentTime) and the time stamp (dwTime) of the data to be processed (AU) are compared.
If the time stamp (dwTime) of the data to be processed (AU) is after the current time (dwCurrentTime), the process advances to step S76 and actual scene composition is performed. If the time stamp (dwTime) of the data to be processed (AU) is before the current time (dwCurrentTime), it is determined that the data is inappropriate to scene composition (the data cannot be used at a scene composition time). Then the process moves to step S75 and the next data block to be processed (AU) is set as a processing object.
FIG. 8 is a time-line chart of the time adjustment processing shown in FIG. 7.
Referring to FIG. 8, an Object stream (AU0) arrives at BIFSDecoder 33 or Decoding Buffer 81 of Decoder 34 at a time Arrival(AU0), is then decoded, and is sent to Composition Memory 82 of Presenter 35 at a time corresponding to a time stamp DTS(AU0) added at the time of encoding, to be used in scene composition from a scene composition time CTS(CU0).
Similarly, the following object stream (AU1) is transferred from Decoding Buffer 81 to Composition Memory 82 at a time DTS(AU1) to be used in scene composition from CTS(CU1).
It can be understood from FIG. 8 that if DTS in Decoding buffer 81 is after the actual current time dwCurrentTime as shown in FIG. 7, it is adjusted to the actual scene composition time CTS in Composition memory 82.
FIG. 9 shows a process formed by adding processing in an IPMP System to the process shown in FIG. 6. Details of this process are as described below.
The same steps as those in FIG. 6 are first performed. That is, FlexDenux 31 receives an MPEG-4 bit stream and separates it into elementary streams (ES) with respect to the kinds of object data, and ALManager 32 divides the ES of each kind of object data on a decoding unit basis.
Next, from the object data divided by ALManager 32, a protected stream is identified on the basis of information relating particularly to IPMP, and IPMP System processing, such as inputting of the proper “key” and authentication, is performed. BIFSDecoder 33 and Decoder 34 then decode Media Streams which are data groups to be decoded with respect to the kinds of object data, and Presenter 35 performs time adjustment of each object and composes and displays scenes one by one.
An example of object data processing flow control will now be described with respect to a case where Test 2 shown in Table 2 is executed under Test Condition #1 and a case where Test 2 is executed under Test Condition #2.
First, in the method using Test Condition #1, the “key”-decipherment time is transmitted as a certain delay in each IPMP System to the decoder. In this case, therefore, no synchronization problem occurs if the supposed total delay is set within a range such as to be absorbed in Composition Layer 24 shown in FIG. 4 or Presenter 35 shown in FIG. 5.
On the other hand, processing in the case of the method using Test Condition #2 is as described below.
FIG. 10 is a flowchart for explaining processing in an IPMP System in a case where Test 2 is executed under Test Condition #2.
First, in step S101, a stream of each object divided on the decoding unit basis is obtained by ALManager 32. In step S102, a determination is made as to whether or not the proper “key” has been input. If it is determined that the proper “key” has not been input, the process advances to step S103 and the protected stream is held without being deciphered. If the proper “key” has been input, the process moves to step S104 and the protected stream is deciphered and the next processing is started.
In the case where Test 2 is executed under Test Condition #2, and where the flow control shown in FIG. 10 is performed, processing of a steam requiring inputting of the proper “key” is suspended. On the other hand, a non-protected stream or a stream already deciphered after authentication on inputting of the proper “key” successively undergoes time synchronization processing for decoding and scene composition. The lapse of time including the time period for authentication and decipherment of the suspended stream on inputting of the proper “key” before a start of the next processing is not a fixed time period, because different user interactive operations are performed with respect to each of the protected streams. It is also possible that the dwTime is past the dwCurrent Time when the processing is restarted.
In such a case, as is apparent from FIGS. 7 and 8, the stream on which processing is restarted is not decoded until a dwTime after the dwCurrentTime appears after the restarting. The stream portion before the next data to be processed (AU) is skipped (that is, the data is thinned out), and the skipped portion is not used in scene composition.
IPMP information for MPEG-4 objects is to have an IPMP Message structure based on using the IPMP_Descriptor for identifying an IPMP stream with respect to each of objects which is described in ISO/IEC SC29 IS14496-1(System) 8.3.2.5 IPMP message syntax and semantics specified by the International Organization for Standardization, and which is shown in FIG. 11.
ISO/IEC SC29 IS14496-1(System) 8.3.2.5 IPMP message syntax and semantics reads as follows.
8.3.2.5 IPMP message syntax and semantics8.3.2.5.1 Syntaxclass IPMP_Message( )extends ExpandableBaseClass{bit(16) IPMPS_Type;if (IMPMS_Type == 0){bit(8) URLString[sizeOfClass-2];}else{bit(8) IPMP data[sizeOfClass-2];}}8.3.2.5.2 Semantics
The IPMP_Message conveys control information for an IPMP System.
IPMPS_Type-the type of the IPMP System. A zero value does not correspond to an IPMP System, but indicates the presence of a URL. A Registration Authority as designated by the ISO shall assign valid values for this field.
URLString[ ]-contains a UTF-8[3]encoded URL that shall point to the location of a remote IPMP_Message whose IPMP_data shall be used in place of locally provided data.
IPMP_data-opaque data to control the IPMP System.
The important point here is that when an IPMP System in conformity with the ISO standard is used, it is registered by a Registration Authority and a unique ID is provided from the Registration Authority.
A standard specification has been planned such that the zeroth value of an ID number designates an IPMP System at an external URL destination, 1 to 2000h (in hexadecimal) are a reserve for ISO, 2001h to ffffh are numbers for ID assigned by a Registration Authority.
FIG. 12 shows a case (Case 1) where a client user A obtains and reproduces an MPEG-4 content or object having IPMP information corresponding to IPMPS_Type 2001h from a server B.
If the user's reproducing device has already been provided with IPMPS_Type 2001h, user authentication such as that described above is performed and decryption using the user's key information, etc., are performed to normally reproduce the content.
On the other hand, in a case where, as shown in FIG. 13 (Case 2), user A tries to further obtain and reproduce an MPEG-4 content or object having IPMP information corresponding to IPMPS_Type 2021h from a server C, it is necessary for the user to obtain an IPMP System in accordance with IPMPS_Type 2021h to enable reproduction. In this case, there are three considerations as described below.    1. The existing user A's device (a device compatible with IPMPS_Type 2001h) may be incapable of obtaining an IPMP System of a different IPMS_Type. There is a need for a common platform compatible with each IPMP System.    2. If one MPEG-4 content has a multi-object configuration with IPMP System information corresponding to different IPMPS_Types, reproduction of the content requires IPMP Systems necessary to different objects, and it is possible that physical requirements in terms of the memory capacity, the processing speed, etc., of the device are not satisfied. The user must know whether the device can operate a plurality of different IPMP Systems.    3. User authentication is required with respect to each of different IPMP Systems. Therefore, a problem relating to synchronization between objects for real-time processing or the like may arise in some case. This problem is indeterminable because of its dependency on the object configurations of contents and on authentication methods.
A specification of a common platform called OPIMA and an application interface (API) has been proposed on consortium level by supposing a case shown in FIG. 13 (case 2) and considering the problem 1 in particular.
Even if the OPIMA kernel are implemented in different devices or application systems, the problems 2 and 3 remain unsolved. In practice, it is difficult for a device which has a restricted component mount space, and whose memory capacity, battery capacity and CPU power are therefore limited, e.g., a portable telephone, to simultaneously have a plurality of different IPMP Systems and to perform processing using the IPMP Systems.
On the other hand, standardization by unifying all IPMP Systems into one entails a drawback in that if a security system such as IPMP is made ineffective by an illegal act, such as hacking, content (or object) right holders sustain great damage. The process of setting a new standard IPMP System and putting products in conformity with the new standard into the market is assumed to require a longer time in comparison with a similar process on company or business world level, because the process includes specifying a universal standard, a country representative voting procedure, or the like.